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(54) A web server request classification system that classifies requests based on 
users'behaviors and expectations 



(57) A server application system includes a server 
application module that performs predetermined func- 
tions in response to external user requests. The server 
application system further includes a characterization 
module coupled to receive the external user requests, 
and to determine a threshold for user tolerance of delay 
for each of the user requests. Tolerance threshold is cal- 
culated using task type, service level, and session du- 



ration. A classification module is then coupled to the 
characterization module to dynamically assign each of 
the user requests an allowable processing deadline 
based on the corresponding usertolerance threshold of 
that user request. The processing deadline specifies the 
time period within which the particular user request must 
be serviced by the server application module. A method 
of admitting incoming user requests to a server applica- 
tion is also described. 
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Description 

BACKGROUND OF THE INVENTION 

1. Field of the Invention 

[0001] The present invention pertains to the Internet/ 
Intranet systems. More particularly, this invention re- 
lates to a web server request classification system that 
classifies requests based on individual user's behavior 
and expectation. 

2. Description of the Related Art 

[0002] With the rapid growth of the I nternet, more and 
more business and residential users are beginning to 
rely on the Internet for their mainstream and mission- 
critical activities. As is known, the Internet typically re- 
fers to a number of data service systems connected to- 
gether via a high speed interconnect network (see Fig- 
ure 1). Each data service system typically includes In- 
ternet server applications that host contents for various 
customers. The data service system can also host other 
applications. Remote user terminals (e.g., terminals 
11a-11n in Figure 1) may be connected to a data service 
system (e.g., the data service system 20 in Figure 1 ) via 
an interconnect network. Each user terminal is equipped 
with a web browser (or other software such as an e-mail 
software) that allows its user (i.e., a person) to access 
the contents and/or applications hosted in various data 
service systems through the corresponding user termi- 
nal. 

[0003] Popular Internet applications include World 
Wide Web (WWW), E-mail, news, and FTP applications. 
All of these applications follow the client-server model 
and rely on the Transmission Control Protocol (TCP) for 
reliable delivery of information/applications between 
severs and user terminals. These applications can also 
be referred to as server applications, A user can access 
a server application (e.g., web server) by generating at 
least one request from a corresponding user terminal to 
the corresponding server application. The server appli- 
cation then services the request. A server application 
can be accessed by multiple user terminals at the same 
time. The server application typically serves the user re- 
quests in the first-in -first- out (FIFO) fashion. 
[0004] One problem of the above-identified prior art 
server application is that it does not have protection 
mechanism against excessive load conditions. Unbear- 
ably long delays or even deadlocks may occur when the 
total number of user requests received by the server ap- 
plication at one time greatly exceeds the total number 
of access requests permitted by the server application 
(i.e., the entire system is overloaded). 
[0005] Another problem is that the server application 
does not provide performance stabilities to its custom- 
ers that host their content/service sites in the server ap- 
plication. This means that the prior art server application 



does not provide features like performance stability over 
a range of client demands, non-interference perform- 
ance among co-hosted content sites, targeted perform- 
ance, and overload protection for the hosted content 
sites. 

[0006] To overcome these problems, prior proposals 
have been made to add quality-of-service (QoS) mid- 
dleware in the server application. The QoS middleware 
classifies requests into different classes. For example, 
the QoS middleware classifies a request as an existing 
session premium request if the incoming request is part 
of an existing session and requires preferred treatment. 
If the request is part of an existing session but does not 
require preferred treatment, the QoS middleware can 
classify the request as an existing session basic re- 
quest, if the incoming request is not part of an existing 
session, then the middleware can classify the request 
as a new session request. 

[0007] Disadvantages are, however, still associated 
with this prior approach. One disadvantage is that the 
classification criteria does not take into account the user 
expectation or tolerance of latency. Studies have shown 
that users become less tolerate of delay as they proceed 
with a session. Prior art middleware provides the same 
treatment to each request within a class, regardless 
whether the request is in the earlier part or later part of 
a session. So if the middleware needs to send a request 
from a class (e.g., the existing session basic class) to 
the server application, the middleware will only pick one 
request based on the FIFO order. This means that the 
middleware does not give any consideration to user tol- 
erance during its classification and scheduling. If the 
middleware treats a request that occurs late in a session 
the same way as it treats a request that occurs early in 
a session, the users of late-session requests may per- 
ceive unacceptably long delays although the actual la- 
tency time for all the requests is about the same. 

SUMMARY OF THE INVENTION 

[0008] One feature of the present invention is to im- 
prove performance and user satisfaction obtained from 
a server application. 

[0009] Another feature of the present invention is to 
provide an intelligent request classification system that 
considers user tolerance when classifying and schedul- 
ing incoming requests to a server application. 
[0010] Another feature of the present invention is to 
design a request classification and scheduling system 
for a server application that has knowledge of human 
behavior and expectation such that the request classi- 
fication and scheduling system can act according to us- 
ers' subjective expectation of the performance of the 
server application. 

[001 1] A further feature of the present invention is to 
dynamically assign processing deadlines to various us- 
er requests based on the assessed user tolerance val- 
ues of these requests. 
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[0012] A still further feature of the present Invention 
is to characterize the user expected delays in process- 
ing their user requests and then process these user re- 
quests accordingly. 

[0013] A server application system includes a server 
application module that performs predetermined func- 
tions in response to external user requests. The server 
application system further includes a characterization 
module coupled to receive the external user requests, 
and to determine user tolerance threshold of each of the 
user requests. A classification module is then coupled 
to the characterization module to dynamically assign 
each of the user requests an allowable processing 
deadline based on the predicted user tolerance thresh- 
old of that user request. The processing deadline spec- 
ifies the time period within which the particular user re- 
quest must be serviced by the server application mod- 
ule. 

[0014] A method of admitting incoming user requests 
to a server application includes the step of determining 
user tolerance threshold of each of the user requests. 
Then the user tolerance thresholds of the user requests 
are used to dynamically assign each of the correspond- 
ing user requests an allowable processing deadline. 
The processing deadline specifies the time period within 
which the particular user request must be serviced by 
the server application module. 
[0015] Other features and advantages of the present 
invention will become apparent from the following de- 
tailed description, taken in conjunction with the accom- 
panying drawings, illustrating by way of example the 
principles of the invention. 

BRIEF DESCRIPTION OF THE DRAWINGS 

[001 6] Figure 1 schematically shows the overall struc- 
ture of the Internet. 

[001 7] Figure 2 shows the structure of a server appli- 
cation system that includes a quality-of-service (QoS) 
middleware that implements one embodiment of the 
present invention. 

[0018] Figure 3 shows different user expectations at 
different levels of services. 

[0019] Figure 4 shows the finding that users' toler- 
ance for latency decreases over the duration of interac- 
tion with a web site, 

[0020] Figure 5 is a flowchart diagram showing the 
process of the characterization module of Figure 2. 
[0021] Figure 6 shows the lookup table for session du- 
rations for various users of the server application system 
of Figure 2. 

DETAILED DESCRIPTION OF THE INVENTION 

[0022] Figure 2 shows a server application system 30 
that includes a qualtty-of-service (QoS) middleware 31 
that implements one embodiment of the present inven- 
tion. In one embodiment, the server application system 



30 is a TCP/I P-based server application system. A TCP/ 
IP-based server application system is a connection- 
based client-server system. An example of such a sys- 
tem is a web content server, an e-mail server, a news 

5 server, an e-commerce server, a proxy server, a domain 
name server, and a local service server, this means that 
the server application system 30 can be any one of the 
above-mentioned servers. Alternatively, the server ap- 
plication system 30 is applicable to any system in which 

to connection-oriented communication is used for data ex- 
change. 

[0023] As will be described in more detail below, the 
QoS middleware 31 includes a characterization module 
45 that receives external user requests. The character- 
's ization module 45 then determines user tolerance 
threshold of each of the user requests received. The 
characterization module 45 determines the user toler- 
ance threshold of a user request based on a combina- 
tion of the level of service promised to the user request, 
20 the session duration of the user request, and the task 
type of the user request. This means that the character- 
ization module 45 can base its determination on any 
one, two, or all of the above mentioned factors. The 
characterization module 45 can extract the session du- 
25 ration of the user request from a cookie of the user re- 
quest, or uses either the IP address or the cookie of the 
user request to look for the associated session duration 
kept in the characterization module 45, In the lattercase, 
the characterization module 45 increments the session 
30 duration each time the server application module 32 is 
accessed by the same user. 

[0024] The task type means that the characterization 
module 45 can classify user requests into many different 
types based on their tasks. For example, the user re- 

35 quests that are just seeking information may be classi- 
fied as the browsing task type user requests while the 
shopping user requests can be categorized as the shop- 
ping task type user requests. By the same token, the 
user requests that are part of some financial transac- 

^0 tionscan be classified as belonging to a transaction task 
type. The task type factor also indicates the user toler- 
ance or expectation of the user requests. This Is be- 
cause users have different tolerance for different tasks. 
For example, people who are shopping may tolerate 

45 longer delays. But people may have shorter patience if 
they want information quickly. The task type information 
is determined by the characterization module 45. The 
different kinds of tasks and tolerances are system-spe- 
cific information for a server application system. For ex- 

50 ample, a shopping site might have browsing tasks that 
are expected to be processed quickly, compute tasks 
that are expected to be slower. What is important is that 
these expectations are modeled by the users. It is based 
on what the user "believes" should be fast or slow. 

55 [0025] The characterization module 45 then sends 
the user tolerance thresholds to the classification mod- 
ule 46. The classification module 46 then dynamically 
assigns each of the user requests an allowable process- 
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ing deadline based on the corresponding user tolerance 
threshold of that user request. The processing deadline 
specifies the time period within which the particular user 
request must be serviced by the server application mod- 
ule 32. 

[0026] The middleware 31 also includes a scheduler 
41 . After the processing deadlines are assigned by the 
classification module 46 to the respective user requests, 
the scheduler 41 coordinates transmission of the user 
requests to the server application module 32 before their 
respective allowable waiting time periods expire. 
[0027] I n summary, the key of the present invention is 
to equip the middleware 31 that handles request classi- 
fication and scheduling with knowledge of human be- 
havior and expectation such that the middleware 31 can 
act according to users' subjective expectation of the per- 
formance of the server application system 30. This 
means that the middleware 31 is an intelligent request 
classification system that can dynamically assign 
processing deadlines to various user requests based on 
their respective user tolerance thresholds. It is, howev- 
er, to be noted that the present invention is not limited 
to be implemented by the middleware 31 . For example, 
the present invention can be implemented in a front end 
load balancer that is outside of the middleware 31 or the 
server application system 30. In this case, the load bal- 
ancer performs the admission classification and sched- 
uling functions. The server application system 30 and 
the middleware 31 will be described' in more detail be- 
low, also in conjunction with Figures 2-6. 
[0028] Referring again to Figure 2, the server appli- 
cation system 30 can be employed by an Internet Serv- 
ice Provider (ISP) to offer data services (e.g., web, 
news, advertisement, or e-mail) and other services (e. 
g. t e-commerce) to users or subscribers connected to 
the server application system 30. Here, a customer 
means the entity contracting with the server application 
system 30 to have its content hosted in the server ap- 
plication system 30, or to have its services offered 
through the server application system 30. A user or sub- 
scriber means the entity accessing the server applica- 
tion system 30 through a remote user terminal via a 
communication network. The user can also be referred 
to as a client. 

[0029] In general, the server application system 30 is 
implemented by or operates in a computer (or data 
processing) system with a network communication ca- 
pability. For example, the server application system 30 
can be implemented by or operates in a servercomputer 
system, a workstation computer system, a mainframe 
computer system, a notebook computer system, or any 
other computer system. 

[0030] The server application module 32 can be any 
TCP/IP-based server application. As described above, 
a TCP/IP-based server application is a connection- 
based client-server. This means that the server applica- 
tion module 32 can be a web content server, an e-mail 
server, a news server, an e-commerce server, a proxy 



server, a domain name server, and a local service serv- 
er. 

[0031] The server application module 32 performs the 
predetermined server function of the server application 

5 system 30. Forexample, if the server application system 
30 is a web server, the server application module 32 per- 
forms the web server function which may include host- 
ing web content and processing requests to retrieve 
their web pages. The server application module 32 is 

10 implemented using any known technology. The struc- 
ture of the server application module 32 is also known 
and dependent on the type of server it implements. 
Thus, the structure of the server application module 32 
will not to be described in more detail below. 

15 [0032] The server application module 32 can be a 
static server or dynamic server. In one embodiment, the 
server application module 32 is a static server that 
stores static files only. In another embodiment, the serv- 
er application module 32 may store both static and dy- 

20 namic files. As is known, web content is generally clas- 
sified as static, such as a file, or dynamic, such as cgi- 
scripts, java-server pages (JSP) or active server pages 
(ASP). Dynamic content may also be generated at run- 
time by a back-end engine (e.g., an application server 

25 or a database engine) that is separate from the server 
itself. 

[0033] The server application module 32 hosts con- 
tent and/or applications that can be accessed by users 
external to the server application system 30. The server 

30 application module 32 can be of any kind of server that 
stores a number of contentfiles. Each of the content files 
can be accessed by an access request. The server ap- 
plication module 32 may also include a number of con- 
tent sites, each storing a number of content files for ac- 

35 cess by multiple access requests. The multiple content 
sites may belong to different content providers or cus- 
tomers. The server application module 32 stores con- 
tent files or dynamic executable code/program for ac- 
cess by requests. Thus, the content files hereinafter re- 

40 fer to (1) static content files, (2) dynamic content files, 
and (3) executable programs/codes. 
[0034] The access to the server application module 
32 may be done by a user at an external user terminal 
. (not shown in Figure 2) who generates and sends at 

45 least one request directed at the server application mod- 
ule 32. Alternatively, an access request may be gener- 
ated by a server application system wanting to access 
the server application system 30. 
[0035] Incoming requests to the server application 

50 module 32 are first received in the middleware 31 from 
an external TCP listen queue (not shown in Figure 2) 
before they are sent to the server application module 32 
for servicing. The external TCP listen queue is within the 
operating system (also not shown) of the computer sys- 

55 tern (also not shown) that runs the server application 
system 30. The external TCP listen queue stores the 
incoming requests before they are processed by the 
server application system 30. 
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[0036] The server application module 32 can process 
multiple requests at the same time. However, the server 
application module 32 has limits on the number of re- 
quests it can process per second. The processing limits 
also depend on the processing power of the server ap- 
plication module 32. 

[0037] The middleware 31 includes a Quality-of-Serv- 
ice (QoS) library 42, which serves as the interface of the 
QoS middleware 31 to the server application module 32. 
The QoS library 42 is invoked by the server application 
module 32 to receive an access request for one of the 
content sites hosted by the server application module 
32. The QoS library 42 also monitors traffic through each 
of the content sites in the server application module 32 
and shares the traffic information with other components 
of the middleware 31 . The QoS library 42 can be imple- 
mented using known technology. Alternatively, the mid- 
dleware 31 does not include the QoS library 42. 
[0038] In addition and as can be seen from Figure 2, 
the middleware 31 also includes an admission controller 
40 and a scheduler 41 . The admission controller 40 fur- 
ther includes a characterization module 45 and a clas- 
sification module 46, each of which can be implemented 
using known technology. For example, each of the mod- 
ules 45-46 can be implemented using known software, 
hardware, or firmware technology. The characterization 
module 45 receives the user requests from the external 
TCP listen queue (not shown in Figure 2). The charac- 
terization module 45 is used to determine the user tol- . 
erance threshold of each of the user request received. 
This will be described in more detail below. 
[0039] The characterization module 45 determines 
the user tolerance level or threshold based on one or 
more factors. These factors include the level of service 
promised to the user, the session duration of the user 
request, the task type of the user request. The charac- 
terization module 45 can calculate the user tolerance 
threshold of a user request based on one of the above- 
mentioned factors, or a combination of the factors (e.g., 
two or three of the factors). Using these factors, the 
characterization process of the characterization module 
45 also takes into consideration of users' subjective ex- 
pectations of the performance of the server application 
module 32 with respect to their user requests. This will 
be described in more detail below. The assigned thresh- 
old can be in the form of time (e.g., seconds). The char- 
acterization module 45 then sends the characterized us- 
er request to the scheduler 41 . 
[0040] The levels of service promised to users can be 
of, for example, two levels (i.e., premium and basic). The 
levels can also be more than two levels. For example, 
the levels can be premium, intermediary, and basic. 
Each user is assigned with a level of service (e.g., either 
premium or basic), which results In all user requests 
from a single user to receive the same level of service 
(e.g., premium or basic). 

[0041] For each level of service, the characterization 
module 45 can determine the corresponding user toler- 



ance level by assigning a predetermined tolerance 
threshold to the level. The predetermined tolerance 
threshold for each service level can be arbitrarily set, or 
based on scientific survey study of the users. Figure 3 

5 shows one study. As can be seen from Figure 3, most 
users rate service quality as high (i.e., good) when the 
latency is below five seconds (for non-incremental load- 
ing) while rating any latency of more than eleven sec- 
onds as low (i.e., bad). In this case, the five second 

10 threshold can be assigned to the premium user requests 
while the eleven second threshold can be assigned to 
the basic user requests. 

[0042] Referring back to Figure 2, the session dura- 
tion of the user request factor means that the character- 
's ization module 45 assigns a usertolerance threshold to 
a user request based on the session duration of that us- 
er request. This means that the characterization module 
45 assigns the usertolerance threshold to the user re- 
quests based on their session durations. Session is de- 

20 fined as a series of accesses from a single user for a 
task or transaction. The session length or duration 
means the number of accesses from a single user ac- 
cessing a site at the server application module 32. 
[0043] This session duration measurement is very in- 

25 dicative of user tolerance. A central finding in a user tol- 
erance survey is that users* tolerance for latency de- 
creases over the duration of interaction with a site. Fig- 
ure 4 shows that finding. In Figure 4, the curve 60 rep- 
resents six second latency. The curve 61 represents ten 

30 second latency. The curve 62 represents sixteen sec- 
ond latency. As can be seen from Figure 4, the effect of 
users' decreased tolerance for latency as session dur- 
ing increases is apparent for both relatively low and rel- 
atively high levels of delay. A sixteen second latency is 

35 acceptable to 60% participants during the first four web 
page accesses, but not acceptable to anyone for ac- 
cesses over the thirteenth page. This is extremely sig- 
nificant, as e-commerce sites generally have a fairly in- 
volved site where a transaction is composed of many 

40 web page accesses. A six-second latency was rated as 
acceptable for all participants until the third page access 
and then the number of users that rated it as acceptable 
declines steadily to 80% for twenty or more accesses. 
[0044] If an e-commerce site wishes to make its site 

45 performance acceptable, then the site must improve the 
latency of a particular user over the duration of a ses- 
sion. This means that the characterization module 45 of 
Figure 2 needs to reduce latency of a user request as 
its session length increases. If a user request has a rel- 

50 ativeiy long session duration, the characterization mod- 
ule 45 needs to assign a user tolerance threshold with 
shorter waiting time. 

[0045] Referring back to Figure 2, the characteriza- 
tion module 45 determines the session duration or ses- 
55 sion length of a user request from the user request itself. 
There are many ways that the characterization module 
45 can determine the session length of the user request. 
In one embodiment, the characterization module 45 can 
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extract the session duration information of the user re- 
quest from a cookie set within the user request. In this 
case, because the cookie is used to identify the same 
user and contains a time stamp that is incremented eve- 
ry time the same user accesses the same site hosted 5 
by the server application module 32, the session dura- 
tion information is extracted from the cookie. In another 
embodiment, the characterization module 45 maintains 
a session duration information for each user accessing 
a site within the server application module 32. When a 10 
user request from a user is received, the characteriza- 
tion module 45 increments the session duration of the 
corresponding user When the characterization module 
45 needs to determine the session duration of a user 
request, the characterization module 45 uses either the 
IP (Internet Protocol) address of the user request or a 
cookie containing the identity of the user to retrieve the 
relevant information. Both of the IP address and the 
cookie identify the user of a particular user request. Al- 
ternatively, other ways can be used to identify user re- 
quests. For example, the user requests can be identified 
by unique cookies. The unique cookies are needed for 
the server application systems that also use proxy serv- 
ers, or when the user requests are generated behind 
firewalls. Figure 6 shows how the session duration in- 
formation is stored in the characterization module 45. 
[0046] As can be seen from Figure 6, the session du- 
ration information is stored in the characterization mod- 
ule 45 in a lookup table (e.g., table 90) format. As can 
be seen from Figure 6, the users field 91 has many en- 
tries based on the IP addresses (i.e., IP1, IP2, ... IPn). 
The session duration field 92 has entries for session du- 
ration values, each corresponding to one IP address. 
When the characterization module 45 needs to know the 
session duration of a user request, the characterization 
module 45 uses the IP address to locate the correspond- 
ing session duration value in the lookup table. Alterna- 
tively, the IP address can be replaced with cookies 
(since cookies also identify the users rather than indi- 
vidual user requests). 

[0047] The classification module 46 is used to assign 
the allowable processing deadline (i.e., the allowable 
waiting time or latency) to each user request based on 
the user tolerance threshold of the respective user re- 
quest. As described above, the allowable processing 
deadline specifies the allowable time period within 
which the user request must be serviced by the server 
application module 32. The classification module 46 
then sends the classified user requests to the scheduler 
41. 

[0048] The scheduler 41 is used to store the user re- 
quests that have been characterized and classified by 
the admission controller 40. This means that each of 
these user requests received by the scheduler 41 has 
a processing deadline threshold that specifies the allow- 
able waiting time for that user request. The scheduler 
41 then coordinates transmission of the user requests 
to the server application module 32 before their respec- 



tive allowable waiting time periods expire. The schedul- 
er 41 does this in connection with the resource limita- 
tions of the server application module 32. Thus, if the 
allowable waiting time for a user request is expiring and 
the server application module 32 does not have any re- 
source to process this particular user request, one ap- 
proach the scheduler 41 can have is to discard the user 
request and close the connection of that request. The 
scheduler 42 can also put that request in a discard 
queue (not shown) to see if the resources of the server 
application module 32 can be freed up in the next one 
or two processing cycles. The scheduler 41 can be im- 
plemented using known technology. 
[0049] Figure 5 shows in flowchart diagram form the 
process of the characterization module 45 in character- 
izing a user request received. As can be seen from Fig- 
ure 4, the process starts at the step 70. At the step 71 , 
the characterization module 45 receives a user request. 
At the step 72, the characterization module 45 deter- 
mines the level of service promised to the user request. 
Alternatively, the characterization module 45 does not 
perform this step. At the step 73, the characterization 
module 45 determines the session duration of the user 
request. Alternatively, the characterization module 45 
does not perform this step. At the step 74, the charac- 
terization module 45 determines the task type of the us- 
er request. Again and alternatively, the characterization 
module 45 does not perform this step. At the step 75, 
the characterization module 45 determines the user tol- 
erance level of the user request based on one, some, 
or all of the factors. Then at the step 76, the process 
determines if more requests have been received by the 
characterization module 45. If so, the process returns to 
the step 71 . If not, the process ends at the step 77. 
[0050] In the foregoing specification, the invention 
has been described with reference to specific embodi- 
ments thereof. It will, however, be evident to those 
skilled in the art that various modifications and changes 
may be made thereto without departing from the broader 
spirit and scope of the invention. The specification and 
drawings are, accordingly, to be regarded in an illustra- 
tive rather than a restrictive sense. 



45 Claims 

1 . A server application system, comprising: 

a server application module that performs pre- 
so determined functions in response to external 

user requests; 

a characterization module coupled to receive 
the external user requests, and to determine 
user tolerance threshold of each of the user re- 
55 quests, and 

a classification module coupled to the charac- 
terization module to dynamically assign each of 
the user requests an allowable processing 
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deadline based on the corresponding user tol- 
erance threshold of that user request, wherein 
the processing deadline specifies the time pe- 
riod within which the particular user request 
must be serviced by the server application 
module. 

2. The server application system of claim 1, further 
comprising a scheduler that coordinates transmis- 
sion of the user requests to the server application 
module before their respective allowable waiting 
time periods expire. 

3. The server application system of claim 1, wherein 
the characterization module determines the user 
tolerance of a user request based on a combination 
of the level of service promised to the user request, 
the session duration of the user request, and the 
task type of the user request. 

4. The server application system of claim 3, wherein 
the characterization module extracts the session 
duration of the user request from a cookie contained 
in the user request. 

5. The server application system of claim 3, wherein 
the characterization module uses either the IP ad- 
dress or the cookie of the user request to look for 
the associated session duration kept in the charac- 
terization module, wherein the characterization 
module increments the session duration each time 
the server application system is accessed by the us- 
er who generated the user request. 

6. The server application system of claim 5, wherein 
the characterization module uses the source IP ad- 
dress, the destination IP address, or a combination 
of both to look up the session duration. 

7. A method of admitting incoming user requests to a 
server application, comprising: 



mining user tolerance of a user request is based on 
a combination of the level of service promised to the 
user request, the session duration of the user re- 
quest, and the task type of the user request. 

5 

10. The method of claim 9, wherein the step of deter- 
mining user tolerance further comprises the step of 
extracting the session duration of the user request 
from a cookie of the user request. 

10 

11. The method of claim 9, wherein the step of deter- 
mining usertolerance further comprises the steps of 

creating a session duration for a user and in- 
15 crementing a session duration for a user each 

time the server application is accessed by the 
user; 

using either the IP address or the cookie of a 
user request to look for the associated session 
20 duration kept in the server application. 

12. The method of claim 11, wherein when the IP ad- 
dress used to look for the associated session dura- 
tion kept in the server application uses source IP 

25 address, the destination IP address, or a combina- 
tion of both to look up the session duration. 

13. The method of claim 9, wherein the step of deter- 
mining usertolerance of a user request further com- 

30 prises the step of determining the task type of the 
user request. 

14. The method of claim 9, wherein the step of deter- 
mining user tolerance further comprises the step of 

35 determining the level of service promised to the us- 
er request. 



40 



determining usertolerance threshold of each of 
the user requests; 

dynamically assigning each of the user re- 45 
quests an allowable processing deadline based 
on the corresponding user tolerance threshold 
of that user request, wherein the processing 
deadline specifies the time period within which 
the particular user request must be serviced by 5 o 
the server application module, 

8. The method of claim 7, further comprising the step 
of transmitting the user requests to the server ap- 
plication module before their respective allowable ss 
waiting time periods expire. 

9. The method of claim 8, wherein the step of deter- 
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START 



•70 



RECEIVE A USER REQUEST 



DETERMINE THE LEVEL OF 
SERVICE PROMISE TO THE 
USER REQUEST 



•72 



DETERMINE THE SESSION 
LENGTH OF THE USER REQUEST 



73 



DETERMINE THE TASK 
TYPE OF THE USER REQUEST 



74 



DETERMINE USER TOLERANCE 
VALUE OF THE USER REQUEST BASED 
ON THE COMBINATION OF THE LEVEL 
OF SERVICE, SESSION DURATION, 
TASK TYPE OF THE USER REQUEST 




figures 



11/9/04, EAST Version: 2.0.1.4 



EP1 172 738 A2 



cc 



CO 
GO 
UJ 
GO 



CO 

cc 



CO 







UJ 


UE 










> 


> 


z . 




o 


o 




h- 




■< 


cc 


QC 




ZD 


a 


a 



Csj 



c: 
a. 



11/9/04, EAST Version: 2.0.1.4 



